前言

是說前幾年 MVC, 3 tier architecture 大紅大紫。

可能 backend 一上手，這些 pattern 我都有 (單押)。

好啦其實現在也還是無敵紅，多虧 Spring Framework 的荼毒 (請期待明天)。

不過今天是來聊聊程式長相的 (你以為選女朋友？又歐飛)

當初我是被一個特有名詞吸引到，才進而認識這兩個東東

"Anemic Domain Model"

在這邊借用馬丁大神的文章 https://martinfowler.com/bliki/AnemicDomainModel.html

什麼你說你不認識他！？沒關係，知道了就會知道這位大師發明專有名詞功力了得，很多你早聽過了。

那我們就先從貧血開始吧！

Anemic Domain Model 貧血的領域模型

你484想問，這麼酷炫的名字怎麼來的，沒錯，我當時就是被名字吸引過來。

但這也並不奇特，如果你受 Spring Framework 荼毒夠深，通常一個使用 Spring 的專案就長這個樣子。

Domain Model 只剩下 Field 不具有 Method，例如那些只有 Getter 和 Setter 的 POJO 們。
邏輯會有專有的 Component (@Component, @Controller, @Service, @Repository) 物件在處理，基本上 Domain Model 只剩下傳值的作用。
這樣的程式長相，叫做貧血的領域模型。若要講古的話，還可以延伸到 EJB 時期的 Transaction Script Pattern。

DDD (Domain Driven Development) 領域驅動開發

阿不是說好要講充血，怎麼變成 DDD。各位客官沒看錯，充血模型就是 DDD。

但別誤會，小弟還沒有強到可以講 DDD，台灣我記得也有 DDD 的社群，有興趣的朋友不仿找找。

當你的 Domain Model 不只有 Field 還有很多具有業務邏輯的 Method。
那你便不需要過多的元件類別。也會因為這樣提高類別本體的內聚，在加上如果有設計好對外溝通的管道，可以輕鬆符合高內聚低耦合的原則。

PROS. & CONS.

好，上面把充血講的好棒棒，貧血是一副 Anti-Pattern 的樣子。那全天下都用 DDD 就好了阿！

嗯，要是事情這麼簡單，DDD 還不早就紅透半邊天，Spring 應該旁邊吃屑屑才對呀，哈哈。

首先 DDD 最難的就是要有 Domain Experts 去設計 Domain Model，要熟業務又要熟程式設計成本基本上就不低。

整個開發團隊也要改變思維來走 DDD，別的語言有可能很常見，但 Java 說實在還真是少見。

JVM 相關的這些年好像除了本業的 OOP (Object Oriented Programming) 就是在搞 FP (Functional Programming) 了。

加上原先 Spring 那套類事務腳本模式有他的優勢在，如果你的專案較簡單，CRUD做一做邏輯也不複雜，說實在 Spring 真滴快。

如果硬要套上 DDD 就是殺小雞用牛刀了，簡而言之，不要為用而用，選擇適當的工具與技術才能事半功倍。

About Me

Jian-Min Huang

wide range skill set backend engineer

Research, Architecture, Coding, DB, Ops, Infra.

mainly write Java but also ❤️ Scala, Kotlin and Go

http://github.jianminhuang.cc

http://linkedin.jianminhuang.cc

http://note.jianminhuang.cc

yfr.huang@hotmail.com